\chapter{Ontwerp beslissingen}

\section{Algemeen ontwerp}

\npar Zoals eerder al aangehaald, is er gekozen om te werken met sessies die op
een centrale server worden bijgehouden. Een mogelijk alternatief was het
bijhouden van deze sessies op de client. Het probleem dat hierbij rijst is het
wat er moet gedaan worden wanneer de client crasht als deze probeert om een of
meerdere reservaties te bevestigen.

\npar Het voordeel van ons huidige ontwerp is dat het hierboven vermelde
probleem niet voorkomt. Het nadeel is echter dat de klassen \class{NamingServer} en \class{SessionManager} ook
kunnen crashen. Een mogelijke oplossing is het dupliceren van deze
klassen om een crash van een andere op te vangen. Dit zorgt
natuurlijk voor redundanditie in het systeem, maar is nodig om faling op te
vangen. Dit is echter niet ge\"implementeerd.

\section{Remote en Serializable objecten}

\npar In het huidige ontwerp is gekozen om een \class{CarRentalCompany} Remote
accessible te maken en het dus altijd op de server van het bedrijf te houden. Om
alle nodige functionaliteit te kunnen aanbieden worden dan kleinere objecten zoals \class{Quote}, \class{ReservationContraints} en
\class{CarType} effectief doorgestuurd. 

\npar De remote objecten zijn de \class{CarRentalCompany}, \class{SessionManager}, \class{ManagerSession} en \class{ClientSession}. \class{SessionManager}, \class{ManagerSession} en \class{ClientSession} bevinden zich op dezelfde host aangezien deze klassen allemaal instaan voor het sessiebeheer. \class{CarRentalCompany} draait op een andere host aangezien het bedrijf deze server waarschijnlijk zelf wil beheren. De \class{NamingServer} is momenteel niet remote beschikbaar. Dit betekent dat deze op dezelfde server moet draaien als de \class{SessionManager}. Indien de \class{NamingServer} remote beschikbaar gemaakt wordt kan deze echter ook naar een andere host verplaatst worden. Omdat dit echter niet noodzakelijk is, is voor een eenvoudigere implementatie gekozen.

\npar Enkel \class{CarRentalCompany} en \class{SessionManager} zijn geregistreerd via RMI. Deze klassen moeten geregistreerd worden aangezien zij het toegangspunt zijn tot de rest van een host. Dit is eveneens de reden waarom enkel deze klassen geregistreerd moeten worden. De client heeft slechts \'e\'en toegangspunt nodig tot de externe hosts. Dit zorgt voor een eenvoudige implementatie van het systeem.